Hi @juan131, sorry that this has sat for a while. I'll see about getting some of this static analysis and unit tests passing today and see if some of us can take a look soon at getting this reviewed and merged.

@willmurphyscode I addressed all the linter warns reported by poetry run make lint-fix but the static analysis is failing and I'm not 100% sure the reason since it's complaining about pieces of code that are copy-pasted from other providers

Hi @wagoodman @willmurphyscode, is there anything we can help with at this time?

Hi @carrodher and @juan131! Thanks for the PR!

is there anything we can help with at this time?

Do you have an image or Dockerfile that you'd expect to exhibit vulnerabilities pulled in from this feed?

The best end-to-end test here would be to find/make an image that has vulnerabilities reported by the new feed, and then bake a new grype database from this branch and make sure that when grype uses the new database, it finds the new vulnerability.

We are happy to do some of the boring stuff (like making linters pass) but it would be super helpful if you all could find/make an image or Dockerfile for us to use in an end-to-end test.

Hi @willmurphyscode

Every Bitnami container image contains one or multiple SPDX files containing the containers BOM. The vulnerabilities associated to the packages listed on these SPDX files can be found in the Bitnami Vulnerability Database. This is explained in the link below:

• https://github.com/bitnami/vulndb?tab=readme-ov-file#how-to-consume-this-cve-feed

After going some more looking, it seems like this is blocked on getting anchore/grype-db#217 merged, and adding a transformer for the new OSV schema. (Without that work, we can't make a grype database that includes the Bitnami data, so we can't run an end-to-end test, so we can't know that this PR is really working.)

After that, we can build a test image to add end to end tests to this PR, clean up linting, and then get this merged.

I'm going to take a look at anchore/grype-db#217 first.

So I was wrong about anchore/grype-db#217 being the first step. I think the first step is really anchore/syft#3065. In other words, the tools need detect the Bitnami packages and encode them in the SBOM in a consistent way before we can match vulnerabilities against them. I'm sorry to hold this up further, but I think the right next step is to figure out answer to the couple of design questions raised in anchore/syft#3065.

Thanks for your patience!

Hi @willmurphyscode

Thanks for looking into this.

the tools need detect the Bitnami packages and encode them in the SBOM

Why is this step required? I mean, Bitnami is already doing this job and ensuring every package is properly described in the SPDX files. AFAIK, the tools should only have capabilities to detect the .spdx files included by Bitnami in the filesystem & recognize them. Maybe I'm missing sth.

Regarding the concern you mentioned at anchore/syft#3065 about duplicates, a mechanism to detect and remove them should be included (e.g. based on the pURL).

@juan131 the reason for the Syft change is that, by default, the SBOM cataloger is off (that is, Syft doesn't incorporate SBOMs it finds in images into the SBOM it produces by default. It used to, but we found this confused people). But I think when we're scanning a Bitnami image, we want to respect the SPDX SBOM we find and raise up those packages. We can discuss details over at anchore/syft#3065.

Hi @willmurphyscode,

I hope you’re doing well! We wanted to check in on the status of our recent contributions. We have some open PRs, and we’re unsure about the current progress or the next steps. Could you kindly provide an update? It would help us plan our work and understand how we can continue contributing effectively.

Here are a couple of the open PRs for reference:

• feat: add support for OSV schema grype-db#217
• feat(vex): CSAF support grype#1826

We appreciate any details you can share. Thanks in advance for your help!